I noticed that ed25519 do not need blake2b. A temporal solution was to remove the object "libsodium_la-blake2b-ref.o" from libsodium.a by using ar dv libsodium.a libsodium_la-blake2b-ref.o I can not remove "qcryptographichash.cpp.o" from libQt6Core.a because I use that on other libraries.

One thing about the static linking problem: it might be as simple as not having the libraries in the correct order.

@jonah765 said in use of STL causing LINK2019 linker error: Thanks a lot for your response, I appreciate the effort, but the error was in the end something trivial. ... and would you like to share the trivial solution? It might help later readers. Thanks

@SGaist Thank you sir for your advise. I solve this issue. By mistake, I put the " \ (backward slash)" before LIBS variable in ChargeDischarge2 .pro file. Now project ChargeDischarge2 is build.

@mranger90 said in How to link an .obj-File in the build process of Qt (qmake): Does adding something like this to your profile work ? OBJECTS_DIR += $$PWD OBJECTS += objtest.o Obviously I tried this on Linux, so drop the ".o" and you may need to replace it with ".obj" Hi @mranger90, ni4882.obj is not really a object, but a linker input file. The real functions are in ni4882.dll. So using LIBS is the correct way, the only strange thing is that the linker input file uses the extension .obj. But this can easily be fixed by renaming. Regards.

Found the error myself. In the include dir there still was the file vtkGUISupportQtModule.h from the vtk-build included which defines VTKGUISUPPORTQT_EXPORT __declspec(dllexport) now its working

@SGaist I sincerely want to thank you for your help! This project took six-months and your assistance was crucial in getting over the goal line in the final week. If I missed that hard deadline my six-month contract-to-hire would have been terminated. Partly because of your assistance I made it work and was hired full-time permanent! We shipped Version 1.0 and two weeks later I delivered a significant V1.1 follow up!. I momentarily had it setup as a (static?)linked library but backtracked to direct #includes from the /common/ folder, mainly because I understood it better. I intend to switch again to the library method because of compile times as you suggested. I was also scared off by an article suggesting I would need to add C++ #EXTERN statements, etc. to create a public interface for the library. Is that true, or can the .pro/.pri files define that folder as a library with NO changes to the C++? I still have to migrate *.qml files to the /common/ but I assume it's basically the same pattern as the C++. I haven't replied because I thought I had more questions but the project has been moving too rapidly. Thank you!

Thanks ! Yes, i have some stuff that doesnt quite need to be there, but it doesnt hurt. I removed all possible linkings and made them "hardcoded". If i add blackflycam.cpp to the sources, therefore it is compiled, i get those errors. If i dont, all runs smooth. The thing is, the code that i replaced with that file, has the exact same includes and non of them are qt-related, so i dont know what the hell is going on here !

Sounds like what I said earlier - the vlc dll was probably compiled with different Qt version than what you're using in your project. These need to match.

That's a good news but still a strange mystery… By the way, no need to modify the thread title, you can mark it as solved using the "Topic Tool" button :)